This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
the original documents submitted by the appUcant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



United States Patent [i9] 

O'Neil et al. 



[11] 

[45] 



null 

US006128279A 
Patent Number: 
Date of Patent: 



6,128,279 
Oct. 3, 2000 



[54J SYSTEM FOR BALANCING LOADS AMONG 
NETWORK SERVERS 

[75] Inventors: Kevin M, O^NeU, Plymouth; Robert F. 

Nerz, Atlleboro; Robert R. Aubin, 
Foxboro, all of Mass. 

[73] Assignee: Web Balance, Inc., Foxboro, Mass. 

[21] Appl. No.: 09A64,499 
[22] FUed: Oct. 1, 1998 

Related 11.S. Application Data 
[60] Provisional application No. 60/071,039, Jan. 13, 1998, and 
provisional application No. 60/061,170, Oct 6, 1997. 

[51] Int. CI.'' H04L 12/28; H04J 1/00; 

G06F 15/16; G06F 9/00 

[52] U.S. CI 370/229; 370/401; 370/402; 

709/223; 709/226; 709/243 

[58] Field of Search 370/229, 480, 

370/259. 401, 524, 231, 402, 237; 709/221, 
223, 238, 105, 226; 395/200.53, 675, 200.31, 
672, 674, 200.54 

[56] References Cited 

U.S. PATENT DOCUMENTS 



5,539,883 7/1996 AUon ct al. . 

5,774,660 6/1998 Brendel et al 395/200.31 

5,774,668 6/1998 Choquicr et al 395/200.53 

5,867,706 2/1999 Martin et al 395/675 

5,923,875 7/1999 T^chi 395/675 

5,978,844 11/1999 Tsuchiya ct al 709/221 



FOREIGN PATENT DOCUMENTS 

2 309 558 7/1997 United Kingdom . 

OTHER PUBLICAHONS 

Shivaratri, N.G., et aL "Load Distributing for Locally Dis- 
tributed Systems," Computer vol 25 (Dec. 1992) No. 12: pp. 
33-44. 

Mourad, A. and Liu, H. "Scalable Web Server Architec- 
tures," IEEE (Jul. 1, 1997): pp. 12-16. 
Kumar, A., et al. "A Model for Distributed Decision Making: 
An Expert System for Load Balancing in Distributed Sys- 
tems," Proceedings of the Annual International Computer 
Sf^hvare and Applications Conference (COMPSAC), Tokyo, 
Oct. 7-9, 1987 No. Conf. 11: pp. 507-513. 

Primary Examiner— Hvy D. Vu 
Assistant Examiner— M. Phan 

Attorney, Agent, or Firm — Nutter, McClennen & Fish LLP; 
David J. Powsner 

[57] ABSTRACT 

A system which distributes requests among a plurality of 
network servers receives a request from a remote source at 
a first one of the network servers, and determines whether to 
process the request in the first network server. The request is 
processed in the first network server in a case that it is 
determined that the request should be processed in the first 
network server. On the other hand, the request is routed to 
another network server in a case that it is determined that the 
request should not be processed in the first network server. 
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SYSTEM FOR BALANCING LOADS AMONG 
NETWORK SERVERS 

This application claims benefit of U.S. Provisional Sen 
Nos. 60/071,039 filed Jan. 13, 1998 and 60/061,170 filed 
Gel. 6, 1997. 

BACKGROUND OF THE INVENTION 

The present invention is directed to a peer-to-peer load 
balancing system which is implemented in plural network 
servers. In particular, the invention is directed to a computer- 
executable module for use in network servers which enables 
each server to distribute loads among its peers based on a 
load currently being processed in each server and/or con- 
tents of the network requests. The invention has particular 
utility in connection with World Wide Web servers, but can 
be used with other servers as well, such as CORBA servers, 
ORB servers, FTP servers, SMTP servers, and Java servers. 

Network systems, such as the World Wide Web 
(hereinafter "WWW"), utilize servers to process requests for 
information. Problems arise, however, if one server becomes 
overloaded with requests. For example, if a server becomes 
overloaded, it may be unable to receive new requests, may 
be slow to process the requests that it has already received, 
and may yield server errors. 

Load balancing was developed to address the foregoing 
problems in the art. Briefly, load balancing involves distrib- 
uting requests among plural servers (e.g., dififerent servers 
on a Web site) in order to ensure that any one server does not 
become unduly burdened. 

One conventional load balancing technique involves the 
use of a domain name server (hereinafter "DNS"), in par- 
ticular a "round-robin" DNS. This device, which typically 
operates on the network, is responsible for resolving uni- 
form resource locators or "URLs" (e.g., "www.foo.com") to 
specific IP addresses (e.g., 111.222.111.222). In this regard, 
a Web site having several servers may operate under a single 
URL, although each server is assigned a different IP address. 
A round-robin DNS pcrforaas load balancing by routing 
requests to these servers in sequential rotation based on their 
IP addresses. 

While round-robin DNSs can coarsely distribute loads 
among several servers, they have several drawbacks. For 
example, not all requests for connection to a Web site are 
necessarily received by a round-robin DNS. Rather, many 
requests will have been previously "resolved" by a DNS 
local to the requester and remote from the Web site (i.e., a 
"a remote DNS") or by the requester (i.e., the computer that 
issued the request on the WWW). In these cases, resolution 
is based on an address which has been cached in the remote 
DNS or the requestor, rather than by sequential rotation 
provided by the Web site's round-robin DNS. Due to this 
caching, load balancing may not be achieved to a satisfac- 
tory degree. 

DNS-bascd load balancing techniques have another sig- 
nificant drawback. In the event that a Web server fails (i.e., 
the Web server goes oEF-Iine), the Web site has no real-time 
mechanism by which to reroute requests directed to that 
server (e.g., by a remote DNS). Thus, a remote DNS with 
caching capabilities could continue to route requests lo a 
failed server for hours, or even days, after the failure has 
occurred. As a result, a user's connection would be denied 
with DO meaningful error message or recovery mechanism. 
This situation is unacceptable, particularly for commercial 
Web sites. 

As an alternative to the DNS-based load balancing tech- 
niques described above, some vendors have introduced 
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dedicated load balancing hardware devices into their sys- 
tems. One such system includes a device, called a proxy 
gateway, which receives all network requests and routes 
those requests to appropriate Web servers. In particular, the 

5 proxy gateway queries the servers to determine their respec- 
tive loads and distributes network requests accordingly. 
Responses from the servers are routed back to the network 
through the proxy gateway. Unlike the DNS-based schemes, 
all requests resolve to the IP address of the proxy server, 

10 thereby avoiding the risk that remote DNS caching or failed 
servers will inadvertently thwart access to the site. 

While proxy gateways address some of the fundamental 
problems of load balancing described above, they also have 
several drawbacks. For example, proxy gateways add 

15 latency in both the "request" direction and the "response" 
direction. Moreover, since the proxy gateway is, for all 
intents and purposes, the only way into or out of a Web site, 
it can become a bottleneck thai limits the capacity of that site 
to the capacity of the proxy gateway. Moreover, the proxy 

20 gateway is also a single point of failure, since its failure 
alone wiU prevent access to the Web site. 

An IP redirector is a device similar to a proxy gateway 
which also performs load balancing. Like a proxy gateway, 
an IP redirector serves as a hub that receives and routes 
requests to appropriate servers based on the servers' loads. 
IP redirectors are different from proxy gateways in that IP 
redirectors do not handle responses to requests, but rather let 
those responses pass directly firom the assigned Web servers 
to the requesters. However, IP redirectors suffer from many 
of the same drawbacks of the proxy gateways described 
above, particularly insofar as limiting the capacity of the 
Web site and preventing access to it as a result of failure of 
the IP redirector. 

25 Dedicated load balancers, such as proxy gateways and IP 
redirectors, also have drawbacks related to sensing loads in 
different Web servers. Using current tedinologies, a server 
can become busy in a matter of milliseconds. A load 
balancer, however, can only query various servers so often 
without creating undesirable overhead on the network and in 
the servers themselves. As a result, such load balancers often 
must rely on "old" information" lo make load balancing 
decisions. Load balancing tediniques which use this "old" 
information arc often ineffective, particularly in cases where 
such information has changed significantly. 

Dedicated load balancers, such as proxy gateways and IP 
redirectors, also have problems when it comes to electronic 
commerce transactions. In this regard, electronic commerce 
transactions are characterized by multiple sequential 

50 requests from a single client, where each subsequent request 
may need to refer to state information provided in an earlier 
request. Examples of this state information include 
passwords, credit card cumbeis, and purchase selections. 
Problems with electronic commerce arise because an 

55 entire transaction must be serviced by one of plural network 
servers, since only that one server has the original state 
information. A load balancer therefore must identify the first 
request of a statcful transaction and keep routing requests 
from that requester to the same server for the duration of the 

60 transaction. However, it is impossible for the load balancer 
to know exactly where a transaction begins or ends, since the 
information in the request providing such indications may be 
encrypted (e.g., scrambled) when it passes through the 
dedicated load balancer. In order to maintain an association 

65 between one requestor and one server, dedicated load bal- 
ancers therefore use a mechanism referred to as a "sticky 
timer". More specifically, the load balancer infers which 



03/18/2004, EAST Version: 1.4.1 



6,128,279 

3 4 

requestmay be the start of a statefiil transaction and then sets In other aspects of the invention, the receiving server 

a "sticky timer" of arbitrary duration (e.g., 20 minutes) determines whether to process a request based on its conteDt, 

which routes all subsequent requests from the same e.g., its uniform resource indicator ("URI"). By virtue of this 

requestor to the same Web server, and which renews the feature of the invention, it is possible to limit the server to 

"sticky timer" with each subsequent request. This method is 5 processing certain types of network requests, while routing 

easUy bypassed and may unnecessarUy defeat the load others. Alternatively, it is possible to direct particular 

balancing feature. requests to particular servers, which then may cither process 

Thus, there exists a need for a load balancing technique qj. reroute those requests based on loads currendy being 

which is able to provide more accurate load balancing than handled by the servers, 

the techniques described above, which is able to perform i i_ 1? l • 

accurate lo^d balancing despite cached server addrSses or '° , '° aspects of the mvention, the recemng server 

"maintained" Web browser addresses, which is not a sig- determmeswhich,if any, of its peer servers are off-lme. The 

nificant bottleneck or source of single point failure, and ^^^^^ '^^^^ acquests to its on-lme peers and does not 

which is able to maintain the association between a cUent route requests to its off-line peers. A server may also assume 

and a server in order to preserve state information required t^e network identity (i.e., the IP address and/or URL) of an 

to complete an electronic commerce transaction. off-line peer to insure that requests are serviced properly 

01 Tk^»* A uv r^c Tut? rvn/cKmr^M directed to an off-line peer by virtue of caching in a 

SUMMARY OF THE INVENTION ^^^^^^ ^^^^^ ^^^j^ ^^^^^^^ ^^.^ 

The present invention addresses the foregoing needs by own identity and its assumed identity until the oflf-hne peer 

providing, in one aspect, a plurality of network servers returns to on-line service. As a result, it is possible to reduce 

which directly handle load balancing on a peer-to-peer basis. 20 response errors resulting from requests being inadvertenUy 

TTius, when any of the servers receives a request, the server directed to off-line servers. 

cither processes the request or routes the request to one of its , , ^ . ■ . . ^ 
peers-depending on their respective loads and/or on the aspects of the invention, servers may be config- 
contents of the request. By implementing load balancing ""'^^ recognize specific URIs which designate entry pomts 
direcUy on the servers, the need fordedicated load balancing „ ^t^teful transactions. A server so configured will not 
hardware is reduced, as are the disadvantages resulting from ^^-^0^1^ '^^"^^ ^^^y from itself if they are related to a 
such hardware. Thus, for example, because each server has s>ateful transaction conforming to the URI of the server, 
the capability to perform load balancing, access to a Web site ^ven URIs that arrive in encrypted requests will be 
managed by the server is not subject to a single point of decrypted by the server and, therefore, will be subject to 
failure. Moreover, requests tagged with IP addresses cached ,0 intelligent interpretation in accordance with configuration 
by remote DNSs or the requestor itself are handled in the ^ ^ '^^"^^ ^ electronic commerce transaction corn- 
same way as other requests, i.e., by being routed among the of multiple requests may be processed entirely on one 
load balancing-enabled servers. °^ P^^'^^ ^nce tiie transaction is complete, as 
A network server according to a related aspect of the confirmed by comparing URI information to configuration 
invention exchanges infomiation with its peers regarding 35 "iles^^bsequent requests will again be subject to rerouting 
their respective loads. This exchange may be implemented P^'P^ balancing. 

based on either a query/response or unsolicited multicasts This brief summary has been provided so that the nature 
among the server's peers, and may be encrypted or may of the invention may be understood quickly. A more corn- 
occur over a private communication channel. The exchange plete understanding of the invention can be obtained by 
may be implemented to occur pcriodicaUy or may be trig- 40 reference to the foUowing detailed description of the pre- 
gered by a network event such as an incoming request. In a furred embodiments thereof in connection with the attached 
preferred embodiment of the invention, each server multi- drawings. 

casts its load information to its peers at a regular period (e.g., nF^rRlPTlON OF THF OR AWINfiS 

500 ms). niis period may be set in advance and subse- ^^^^^ DbSCRIFnON Oh JHb 0RAW1N06 

quently re-set by a user In the preferred embodiment, the 45 A more complete understanding of the invention may be 

multicast message serves the dual purposes of exchanging attained by reference to the drawings, in which: 

load information and of confiraiing that a transmitting server p,G ^ ^ diagram showing the topology of a Web site 

is still on-line. including the present invention; 

By virtue of the foregoing, and by virtue of the server FIG. 2. comprised of FIGS. 2A and 28. is a flow diagram 

having nearly mstantaneous mformation regarding its own 50 3howing process steps for distributing requests among vari- 

worWoad, the server is able to make routmg determmations ^^^^ ^^^^ j^^^ ^^^^^^ 

based on substantially up-to-date information. The most . , . . ^ , , 

critical decision, i.e.. whether to consider rerouting, is pref- , ^ "^J^^J'^ "^^^^^^ v.ew of a portion of the topology 

crably made based on the most current information available s*>o*° m RG. 1 relating to load balancmg; 

(i.e., based on a local server load provided nearly instanta- ss FI^. 4 is a flow diagram showmg process steps for 

neously from within the server and without any network distributing requests among various servers based on the 

transmission latency). content of the requests; and 

In further aspects of the invention, a server processes a FIG. 5 is a diagram showing the topology of a Web site 

received request directly when its load is below a first including the present invention and a proxy, 

predetermined level, or if its load is above the first prede- 60 
termined level yet those of the server's peers are above a 
second predetermined level. Otherwise, the server routes the 

request to one of its peers. By equipping a site with muhiples The present invention is directed to a system for imple- 

servers of this type, it is possible to reduce the chances that menting peer-to-peer load balancing among plural network 

one server wilt become overwhelmed with requests while 65 servers. Although the invention will be described in the 

another server of similar or identical capabilities remains context of the World Wide Web ("WWW"), and more 

relatively idle. specifically in the context of WWW servers, it is not limited 
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to use in this context. Rather, the invention can be used in comprise flle servers which store a database for Web site 1. 

a variety of different types of network systems with a variety Back-end Web servers 27 and 29 may be used to access data 

of different types of servers. For example, the invention can files on mainframe 16 (or other similar computer) in 

be used in intranets and local area networks, and with response to requests from server cluster 6. Once such data 

CORBA servers, ORB servers, FTP servers, SMTP servers, 5 files have been accessed, mainframe 16 may tben transmit 

and Java servers, to name a few. t^j^se files back to server cluster 6. Alternatively, data on 

FIG. 1 depicts the topology of a Web site 1 which includes back-end Web servers 27 and 29 may be accessed direcUy 

the present invention, together with hardware for accessing from server cluster 6 without the aid of mainframe 16. 
that Web site from a remote location on the Internet. More 

specifically, FIG. 1 shows router 2, local DNS 4, server First Embodiment 
cluster 6 comprised of Web servers 7, 9 and 10, packet filter 

11, and internal network 12. A brief description of this FIG.2illustratesprocessstepsof the present mvenUon for 

hardware is provided below. load balancing received network requests. To begin, in step 

Router 2 receives requests for information stored on Web ^201 a network request is received at a server, such as server 

site 1 from a remote location (not shown) on the Internet. J^^^ f^^; ^- Tli^/cqu«t may be rcso ved by a remote 

Router 2 routes these requests, which typicaUy comprise 0° *be Internet based on a cached IP address (e.g.. 

URLs, to local DNS 4. Local DNS 4 receives a URL from '^q^f ts 1, 2. 3 and 4) or alternatively, the request may be 

router 2 and resolves the domain name in the URL to a ^^^^^^^ ^ '^"^ round-robm DNS 4 (e.g., request 5). 

specific IP address in server cluster 6. in step 5202, server 7 detennmes a load (e.g., the 

Server cluster 6 is part oftheuntrusted segment 14 of Web complexity of network requests) that it is 

site 1, to which access is relatively unrestricted. Server currently processmg, and the capacity remammg tberem. 

cluster 6 is comprised of a plurality of servers, including Step S203 decides if the load currenUy being processed m 

servers 7, 9 and 10. Each of these servers is capable of server 7 exceeds a first predetermined level. In preferred 

retrieving information from internal network 12 in response embodiments of the invenUon, this predetermined level is 

to requests resolved by a remote DNS on the Internet or by „ ^0%, meaning that server 7 is operating at 50% capacity. Of 

local DNS 4. Included on each of servers 7, 9 and 10 is a ^o^^' invention is not limited to using 50% as the first 

microprocessor (not shown) and a memory (not shown) predetermined level. In this regard, a value for the first 

which stores process steps to effect information retrieval. In prcdetermmcd level may be stored in a memory on server 7, 

preferred embodiments of the invention, each memory is '^^^ may be rcprDgrammcd periodicaUy. 

capable of storing and maintaining programs and other data 33 If step S203 decides that server 7 is not processing a load 

between power cycles, and is capable of being repro- exceeds the first predetermined level, flow proceeds to 

grammed periodically. An example of such a memory is a step S204. In step S204, the network request is processed in 

rotating hard disk. server 7, and a response thereto is output via the appropriate 

The memory on each server also stores a computer- channels. On the other hand, in a case that step 8203 

executable module (i.e., a heuristic) comprised of process 35 determines that server 7 is processing a load that exceeds the 

steps for performing the peer-to-peer load balancing tech- predetenmined level, fiow proceeds to step S205. 

nique of present invention. More specifically, server 7 Step S205 determines loads currently being processed by 

includes load balancing module 17, server 9 includes load server 7's peers (e.g., servers 9 and 10 shown in FIG. 3). In 

balancing module 19, and server 10 includes load balancing more detail, in step S205, load balancing module 17 com- 

module 20. The process steps in these modules are execut- 49 pares its current load information with the most recent load 

able by the microprocessor on each server so as to distribute information provided by load balancing modules 19 and 20. 

requests among the Web servers. In more detail, the process These load balancing modules continuously exchange infor- 

steps include, among other things, code to receive a request mation regarding their respeaive loads, so that this infor- 

fiom a remote source at a first one of the Web servers (e.g., mation is instantly available for comparison. In the example 

server 7), code to determine whether to process the request 45 shown in FIG. 3, load balancing module 19 provides infor- 

in the first server, code to process the request in the first mation concerning the load currently being processed by 

server in a case that the determining code determines that the server 9, and bad balancing module 20 provides informa- 

request should be processed in the first server, and code to tion concerning the load currently being processed by server 

route the request to another server (e.g., server 9) in a case 10. 

that the determining code determines that the request should 50 In step S206, load balancing module 17 determines 

not be processed in the first server. A more detailed dcscrip- whether the loads currently being processed by server 7's 

tion of the load balancing technique implemented by these peers arc less than the load on server 7 by a differential 

process steps is provided below. exceeding a second predetermined level. In preferred 

Packet filter 11 comprises a firewall for internal network embodiments of the invention, this second predetermined 

12 (i.e., the trusted segment) of Web site 1. All transactions 55 level is 20%, which provides a means of assessing whether 

into or out of internal network 12 are conducted through servers 9 or 10 have at least 20% more of their capacities 

packet filter 11. In this regard, packet filter 11 "knows" available than server 7. Of course, the invention is not 

which inside services of internal network 12 may be limited to using 20% as the second predetermined level. In 

accessed from the Internet, which clients are permitted this regard, as above, a value for the second predetermined 

access to those inside services, and which outside services so level may be stored in a memory on server 7, and may be 

may be accessed by anyone on internal network 12. Using reprogrammed periodically. 

this information, packet filler 11 analyzes data packets In a case that step S206 decides that server 7's peers (i.e., 

passing therethrough and fillers these packets accordingly, servers 9 and 10) do not have 20% more of their capacity 

restricting access where necessary and allowing access available, flow proceeds to step S204. In step S204, the 

where appropriate. 65 network request is processed in server 7, and a response 

lotemal network 12 includes mainframe 16 and back-end thereto is output via the appropriate channels. On the other 

Web servers 27 and 29. Back-end Web servers 27 and 29 band, in a case that step S206 decides that at least one of 
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server 7*s peers is prcwessing a load that is less than the FIG. 4 is a flow diagram illustrating process steps corn- 
percent load on server 7 by the second predetermined level, prising this embodiment of the invention. To begin, in step 
flow proceeds to step S207. S401, load balancing module 17 receives a request from 
Step S207 determines which, if any, of the servers at Web either network DNS 21 or from local DNS 4 (see FIG. 3). In 
site 1 are off-line based, e.g., on the load information 5 step S402, the load balancing module then analyzes the 
exchange (or lack thereof) in step S205. A server may be request to determine its content. In particular, load balancing 
off-line for a number of reasons. For example, the server module 17 analyzes the request to identify URIs (or lack 
may be powered-down, malfunctioning, etc. In such cases, thereof) in the request. 

the servers' load balancing modules may be unable to Step S4(t2 determines which server(s) are dedicated to 

respond to a request from load balancing module 17 or 10 processing which URIs, and which server(s) are dedicated to 

otherwise be unable to participate in an exchange of processing requests having no URl. That is, in the invention, 

information, thereby indicating that those servers are off- the load processing module of each server is configured to 

line. In addition, in preferred embodiments of the invention, accept requests for one or more URIs, thus limiting the 

the load balancing modules are able to perform diagnostics server to processing requests for those URIs. For example, 

on their respective servers. Such diagnostics test operation load balancing module 17 may be configured to accept 

of the servers. In a case that a server is not operating requests with a URl of "/banking", whereas load balancing 

properly, the server's load balancing module may provide an module 19 may be configured to accept requests with a URI 

indication to load balancing module 17 that network of "/securities". Which server processes which URI may be 

requests should not be routed to that server "hard-coded" within the server's toading balancing module. 

Next, step S208 analyzes load information from on-line stored within the memory of each server, or obtained and 

servers in order to determine which of the on-line servers is updated via a dynamic protocol. 

processing the smallest load. Step S208 does this by com- In any event, in a case that step S403 decides that server 

paring the various loads being processed by other servers 9 17 is dedicated to processing LRIs of the type contained in 

and 10 (assuming that both are on-line). Step S209 then the request (or no URI, whichever the case may be), flow 

routes the network request to the server which is currently proceeds to step S404. In step S404, the request is accepted 

processing the smallest load. In the invention, routing Is by load balancing module 17 and processed in server 7, 

performed by sending a command from load balancing whereafter processing ends. On the other hand, in a case that 

module 17 to a requestor instructing the requestor to send the step S403 decides that server 7 does not process URIs of the 

request to a designated server. Thus, re-routing is processed type contained in the request, flow proceeds to step S405. 

automatically by the requestor software and is virtuaUy This step routes the request to one of server 7' s peers that is 

invisible to the actual Internet user. dedicated to processing requests containing such URIs. 

Thereafter, that server processes the request in step S210. Routing is performed in the same manner as in step S209 of 

At this point, it is noted, however, that the invention is not FIG. 2. Once the request is received at the appropriate 

Umitcd to routing the request to a server that is processing « server, the load balancing module associated therewith 

the smaUest load. Rather, the invention can be configured to accepts the request for processing by the server in step S406, 

route the request to any server that is operating at or below whereafter processing ends, 

or predetermined capacity, or something similar such as, but ^ ■ j n u j- . 

not limited to, a round-robin hand^ff rotation. Embodimem 

FIG. 3 illustrates load distribution according to the 4q The first and second embodiments of the invention 

present invention. More specifically, as noted above, server described above can be combined into a single embodiment 

7 (more specifically, load balancing module 17) receives which routes network requests based on both a content of the 

requests 1. 2. 3 and 4 resolved by network DNS 21 and request and loads being handled by the various servers. 

request 5 via local DNS 4. Similarly, server 10 receives More specifically, in this embodiment of the invention, each 

request 6 (i.e., a cached request) via local DNS 4. Any of 45 load balancing module is configured to route a request to a 

these requests may be "boolanarked" requests, meaning that server dedicated to a particular URI in a case that the server 

they are specifically addressed to one server. Once each load is operating at less than a predetermined capacity. In a case 

balancing module receives a request, it determines whether that the server is operating at above the predcterinined 

to process that request in its associated server or to route that capacity, the invention routes the requests to another server 

request to another server. This is done in the manner shown 50 which can handle requests for the URI, but which is oper- 

in FIG. 2. By virtue of the processing shown in FIG. 2, load ating at below the predetermined capacity. The methods for 

balancing modules 17, 19 and 20 distribute requests so that performing such routing are described above with respect to 

server 7 processes requests 1 and 2, server 9 processes the first and second embodiments of the invention. 

requests 3 and 5, and server 10 processes requests 4 and 6. ^ ^ 

Fourth Embodmient 

Second Embodmient ^ noted above, the present invention reduces the need for 

In the second embodiment of the invention, load balanc- a proxy gateway or simUar hardware for distributing loads 

ing is performed based on a content of a network request, in among various Web servers. It is noted, however, that the 

this case a URL/URI. As noted above, a URL addresses a invention can be used with such hardware. FIG. 5 shows the 

particular Web site and takes the form of "www.foo.com". A 60 topology of a Web site on which the present invention is 

URI, on the other hand, specifies information of interest at implemented, which also includes proxy 26. 

the Web site addressed by the URL. For example, in a In this regard, except for proxy 26, the features show in 

request such as "www.foo.com/banking", "/banking" is the FIG. 5 are identical in both stmcture and function to those 

URI and indicates that the request is directed to information shown in FIG. 1. Wlh respect to proxy 26, proxy 26 is used 

at the "foo" Web site that relates to "banking". In this 65 to receive network requests and to route those requests to 

embodiment of the invention, URIs in network requests are appropriate servers. A load balancing module on each server 

used to distribute requests among servers. then determines whether the server can process requests 
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routed by proxy 26 or whether such requests should be 
routed to one of its peers. The process for doing this is set 
forth ia the first, second and third emboditnents described 
above. 

5 

Fifth Embodiment 

This embodiment of the invention is directed to a system 
for maintaining aa association between a requester and one 
of pluraJ servers at a Web site when state information is used 
during an electronic transaction. 

More specifically, in accordance with this embodiment of 
the invention, a server at a Web site, such as server 7 shown 
in FIG. 1, is configured to recognize specific URIs (e.g., 
URIs that designate entry points for a stateful transaction 
relating to electronic commerce). In the case that one of 
these URIs is recognized, the server will not route subse- 
quent transactions away from that server, thereby ensuring 
that all such requests arc processed by that server. Requests 
may again be re-routed from the server once a URI which 20 
matches a predetermined "configuration rule" is detected 
(e.g., when a transaction is complete). 

In preferred embodiments of the invention, wild card URI 
information may be used to designate a state fill path. For 
example, the hyperlink "http:/Avww.foo.oomy banking/*" 25 
would mean that "http://www.foo.com/banking/" constitutes 
the entry point into a stateful transaction. Any request up to 
and including this point would be subject to potential 
re-routing. Any request further down this path would indi- 
cate that the requestor and the server are engaged in a 30 
stateful transaction and not subject to potential re-routing. 

TTie present invention has been described with respect to 
particular illustrative embodiments. It is to be understood 
that the invention is not limited to the above-described 
embodiments and modifications thereto, and that various ^5 
changes and modifications may be made by those of ordi- 
nary skill in the art wi±out departing from the spirit and 
scope of the appended claims. 

In view of the foregoing, what we claim is: 
1. A method of distributing requests among a plurality of 40 
network servers, the method comprising the steps of: 
receiving a request from a remote source at a first one of 

the network servers; 
executing a determining step in the first server, the deter- 
mining step for determining whether to process the 
request in the first network server; 
processing the request in the first network server in a case 
that the determining step determines that the request 
should be processed in the first network server; and 
routing the request to another QCtwork server in a case that 
the determining step determines that the request should 
not be processed in the first network server; 
wherein the determining step comprises the steps of: 
determining a load currently being processed by the 5S 

first network server; and 
receiving information in the first network server from 
each of the other network servers, the information 
from each of the other network servers comprising 
information concerning a load currently bemg pro- 60 
cessed in each network server; 
wherein the determining step determines that the first 
network server should process the request in a case 
that (i) the load currently being processed in the first 
network server is below a first predetermined level, 65 
or (ii) the load currently being processed in the first 
network server is above the first predetermined level 



and is above loads currently being processed by 
either of the other network servers by less than a 
second predetermined level; and 
wherein the determining step determines that the first 
network server should not process the request in a 
case that the load currently being processed in the 
first network server is above the first predetermined 
level and a load currently being processed in at least 
one of the other network servers is below the level of 
the first network server by at least the second pre- 
determined level. 

2. Computer-executable process steps stored on a 
computer-readable medium, the computer executable pro- 
cess steps comprising a server module which is installable in 
a plurality of network servers to distribute requests among 
the plurality of network servers, the computer-executable 
process steps comprising: 

code to receive a request from a remote source at a first 

one of the network servers; 
code, executable by the first server, to determine whether 

to process the request in that server; 
code to process the request in the first network server in 

a case that the determining code determines that the 

request should be processed in the first network server; 

and 

code to route the request to another network server in a 
case that the determining code determines that the 
request should not be processed in the first network 
server, 

wherein the determining code comprises: 

code to determine a load currently being processed by 
the first network server; and 

code to receive information in the first network server 
from each of the other network servers, the infor- 
mation from each of the other network servers com- 
prising information concerning a load currently 
being processed in each network server; 

wherein the determining code determines that the first 
network server should process the request in a case 
that (i) the load currently being processed in the first 
network server is below a first predetermined level, 
or (ii) tbe load currently being processed in the first 
network server is above the first predetermined level 
and is above loads currently being processed by 
either of the other network servers by less than a 
second predetermined level; and 

wherein the determining code determines that the first 
network server should not process the request in a 
case that the load currently being processed in the 
first network server is above the first predetermined 
level and a load ciurently being processed in at least 
one of the other network servers is below the level of 
the first network server by at least the second pre- 
determined level. 

3. A network server which is capable of processing 
requests and of distributing the requests among a plurality of 
other network servers, the network server comprising: 

a memory which stores a module comprised of computer- 
executable process steps; and 

a processor which executes the process steps stored in the 
memory so as 

(i) to receive a request from a remote source at the 
network server, 

(ii) to determine whether to process the request in the 
network server by executing process steps so as (a) 
to determine a load cuuently being processed by the 
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first network server, and (b) to receive information in 
the first network server from each of the other 
network servers, the information from each of the 
other network servers comprising information con- 
cerning a load currently being processed in each 
network server; 

wherein the processor determines that the first net- 
work server should process the request in a case 
that (i) the load currently being processed in the 
first network server is below a first predetermined 
level, or (ii) the load currently being processed in 
the first network server is above the first prede- 
termined level and is above loads currently being 
processed by either of the other network servers 
by less than a second predetermined level; and 

wherein the processor determines that the first net- 
work server should not process the request in a 
case that the load currently being processed in the 
first network server is above the first predeter- 
mined level and a load currently being processed 
in at least one of the other network servers is 
below the level of the first network server by at 
least the second predetermined level; 

(iii) to process the request in the network server in a 
case that the processor determines that the request 
should be processed in the network server, and 

(iv) to route the request to another one of the plurality 
of network servers in a case that the processor 
determines that the request should not be processed 
in the network server. 

4. A method of distributing requests among a plurality of 
network servers, the method comprising the steps of; 

receiving a request from a remote source at a first one of 
the networic servers; 

executing a determining step in the first server, the deter- 
mining step for determining whether to process the 
request in the first network server; 

processing the request in the first network server in a case 
that the determining step determines that the request 
should be processed in the first network server; and 

routing the request to another network server in a case that 
the determining step determines that the request should 
not be processed in the first network server; 

wherein the determining step comprises determining 
whether the request is related to a statefiil transaction 
based on a URI in the request; and 

wherein (i) in a case that the request is related to a stateful 
transaction, determining that the request should be 
processed in the first network server, and (ii) in a case 
that the request is not related to a stateful transaction, 
determining if the request should be processed in the 
first network server. 

5. A method according to claim 4, wherein, in a case that 
the request is related to a stateful transaction, determining 55 
that at least a second request having a URI substantially the 
same as the URI of the request should be processed in the 
first network server. 

6. Computer-executable process steps stored on a 
computer-readable medium, the computer executable pro- 
cess steps comprising a server module which is installable in 
a plurality of network servers to distribute requests among 
the plurality of network servers, the computer-executable 
process steps comprising: 
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code to receive a request from a remote source at a first 

one of the network servers; 
code, executable by the first server to determine whether 

to process the request in that server; 
code to process the request in the first network server in 

a case that the determining code determines that the 

request should be processed in the first network server; 

and 

code to route the request to another network server in a 
case that the determining code determines that the 
request should not be processed in the first network 
server; 

wherein the determining code comprises code to deter- 
mine whether the request is related to a stateful trans- 
action based on a URI in the request; and 

wherein (t) in a case that the request is related to a stateful 
transaction, the determining code determines that the 
request should be processed in the first network server, 
and (ii) in a case that the request is not related to a 
stateful transaction, the determining code determines if 
the request should be processed in the first network 
server. 

7. Computer-executable process steps according to claim 
6, wherein, in a case that the request is related to a stateful 
transaction, the code to determine determines that at least a 
second request having a URI substantially the same as the 
URI of the request should be processed in the first network 
server. 

8. A network server which is capable of processing 
requests and of distributing the requests among a plurality of 
other network servers, the network server comprising: 

a memory which stores a module comprised of computer- 
executable process steps; and 

a processor which executes the process steps stored in the 
memory so as 

(i) to receive a request from a remote source at the 
network server, 

(ii) to determine whether the request should be pro- 
cessed in the network server by determining whether 
the request is related to a stateful transaction based 
on a URI in the request; 

wherein (i) in a case that the request is related to a 
stateful transaction, the processor determines that 
the request should be processed in the network 
server, and (ii) in a case that the request is not 
related to a stateful transaction, the processor 
determines if the request should be processed in 
the tKtwork server; 

(iii) to process the request in the network server in a 
case that the processor determines that the request 
should be processed in the network server, and 

(iv) to route the request to another one of the plurality 
of network servers in a case that the processor 
determines that the request should not be processed 
in the network server. 

9. A network server according to claim 8, wherein, in a 
case that the request is related to a stateful transaction, the 
processor determines that at least a second request having a 
URI substantially the same as the URI of the request should 
be processed in the network server. 
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